【CDGC】IDMC Metadataを使ってインフォマティカで作成したETLのリネージュを取得してみた

IDMC Metadataを使ってリアルタイムなETLスキャンを実現してリネージュ取得するまでを、Informatica CDGCの基本操作と共にまとめてみました。

#インフォマティカ

#Intelligent Data Management Cloud

渡部晃季

2024.07.08

 はじめにこんにちは、データ事業本部の渡部です。
今回はインフォマティカのCloud Data Governance and Catalog(以降、CDGC)でIDMC　Metadataという機能を使用してリネージュの取得まで試してみようと思います。
!リネージュというのは「血統」という意味で、イメージしやすいのは家系図かと思います。

今回はデータのリネージュ、つまりデータがどこからやってきてどこに行くのかの流れを表したものです。

競馬好き・ウマ娘好きの方はイメージしやすいかもですね。
CDGCのリネージュ・サンプルは以下の画像のようになります。（インフォマティカさんが書いたブログから拝借しました）

データレイクのS3からSnowflakeを経由して、BIツールのTableauまで一気通貫で表示されています。
「どうしてリネージュを含むメタデータ管理をやるんだ？」という疑問には、以下弊社sutoの記事やTroccoさんの記事がわかりやすかったので添付させていただきます。
https://dev.classmethod.jp/articles/data-management-metadata-think/
https://blog.trocco.io/useful/metadata-management
 IDMC Metadataって？IDMC Metadataはメタデータコマンドセンター（以降、MCC）の一機能です。

IDMC Metadataを有効化することで、Cloud Data Integration(以降、CDI)で作成したETLタスクに加えた変更をほぼリアルタイムでCDGCデータカタログに同期させる ことが可能です。

IDMC Metadataを有効にしたあとに動いたタスクであれば、すべて同期対象とすることができます。
以前までは「Informatica Intelligent Cloud Services カタログソース」というコンポーネントでタスクをスキャンしていたのですが、スケジュールまたは手動でのスキャンとなり、リアルタイムには対応できていませんでした。

対してIDMC Metadataならリアルタイム性のあるスキャンが実現できます。
IDMC Metadataの同期のタイミングは2つ。 実装変更時とタスク実行時 です。

それぞれでスキャンできるアセットは違うので以下に示します。
 実装変更時Mapping
Mapping Task
Project
Folder
Synchronization Task
PowerCenter Task
Dynamic Mapping Task
Replication Task
Masking Task
Linear Taskflow
Taskflow
 タスク実行時Mapping Task
Data Synchronization Task
Replication Task
IDMC Metadataは2024年4月にGA（一般公開）となったばかりの機能ですが、とても強力です。
 やってみる 事前準備備忘も兼ねて、細かく手順を載せていこうと思います。
まずCDGCサービスを有効化しなければ、メタデータのスキャンが不可能なので、有効化します。

管理者画面で以下のとおり設定します。
 ランタイム環境の設定管理者画面でSecureAgentに対する設定変更をします。

まずはSecureAgentをクリックください。
編集ボタンを押して、システム構成の詳細で以下の設定をします。
AutoCatalogServiceMappingFileCopyEnabled：true
AutoCatalogServiceMappingFileLocation：<SecureAgent Install Dir>/apps/Metadata_Platform_Service/data/AutoCatalogServiceMappingFileLocation
AutoCatalogServiceMappingFileLocationには、「powrmart.dtd」というファイルが格納されていました。

中身も見てみてみると、XMLファイルであり、おそらくIDMC Metadataで使用する処理定義のようなものと思われました。
[infa@ip-10-10-0-151 AutoCatalogServiceMappingFileLocation]$ ls -la
total 36
drwxr-xr-x.  2 infa infa    26 Jul  8 15:52 .
drwxr-xr-x. 10 infa infa   169 Jul  7 14:15 ..
-rwxr-xr-x.  1 infa infa 36762 Jul  8 07:50 powrmart.dtd
 IDMC Metadataの有効化と初回スキャン今回の検証のために以下のようなデータパイプラインを作成しました。
ETL設計の論理図は以下の形です。
上記ETLで使用しているCDIタスクをスキャンするための設定を今からしていきます。
サービス一覧からメタデータコマンドセンターを選択ください。
設定を選択します。
IDMCメタデータを有効にする：有効化
ランタイム環境：先ほど設定を編集したSecureAgentグループ
フィルタ条件：スキャンする対象アセットを記述
構成パラメータ：設定しません
公式Documentを見る限り、ここはInformaticaのサポートに指定されたら設定する箇所のようです。

「フィルタどうやって書けばいいかわからないよ」となっても、以下のようにトグルを開くとフィルタ条件の記法が表示されます（便利ですね）。
保存を押すと、スキャンジョブが動き始めます。

このジョブはMetadata synchronization jobsと呼ばれ、CDIのアセット自体のメタデータを取り込むジョブのようです（参考：Monitor IDMC metadata jobs）。

具体的にはアセットやフォルダ・プロジェクトの階層（リレーション）が読み込まれます。
数分ほど待つと、ジョブが完了しました。
ジョブ詳細を確認してみると、IDMC Metadataで設定したプロジェクト配下のアセットが、スキャン数的に一致するのでスキャンされていそうです。
実際にスキャンされているか、CDGCを確認してみます。

参照 > データカタログ を選択します。

スキャンしたかったアセットが表示されていることが確認できました。
アセットの依存関係もリレーションで確認することができます。
しかし画面をくまなく探しても今回のテーマであるリネージュが確認することができません。

それもそのはず、IDMC Metadataの設定保存後に動いたメタデータ抽出ジョブは、あくまでアセットの階層くらいのメタデータしか抽出しないからです。
 リネージュを取得するまでのスキャンと接続割り当て接続やカラム情報まで抽出するには、IDMC Metadata有効後のCDIタスク実行が必要です。

そのためCDIタスクを実行します。
実行完了後、MCCでメタデータスキャンジョブ（Run-time metadata synchronization jobs

）が開始されていることが確認できます。

IDMC Metadata設定時のジョブ履歴はジョブに表示されていたのに対して、IDMCメタデータタブにジョブ履歴が表示されます。
数分後ジョブが完了するので、再度CDGCを確認します。
先程までにはなかったマッピングタスクインスタンスなるものがマッピングタスクのリレーションに表示されています。

選択してみるとリネージュタブが存在しており、データリネージュが取得できていることが確認できました。
カラムレベルでもリネージュが取得できています。
ただしまだこれは完全系ではありません。

冒頭に添付したとおり、接続には各接続に対するアイコンが表示されるはずで、今は少しばかり寂しいです。
実は先ほどのスキャンはconnectionless scanと呼称されるスキャンで、データリポジトリ（今回でいうS3やRedshift）を直接参照するのではなく、予測でリポジトリの情報を表示させています。

予測とはいえタスクからスキャンしているので、的外れなものにはなりませんが、不正確な情報が反映されているかもしれません。
これを解消させるためには、MCCで接続割り当てが必要です。

接続割り当てはMCCでスキャンしたタスクに使用しているInformaticaのコネクタに対して、データリポジトリ（S3やRedshiftなど）カタログソースのメタデータを割り当てる作業となります。
MCCで、監視 > 接続割り当て > 対象の接続を選んで割り当てをします。

たくさん接続を読み込んでいるとリストが混んでいる場合は、検索機能・フィルタ機能を使用しましょう。
すでに読み込んであるS3のカタログソースを割り当てます。
!S3やこの後のRedshiftのスキャン方法については以下記事をご参考ください。
割り当てが完了すると、割り当てジョブが開始されます。
3分ほどで割り当てジョブが完了したので、CDGCにまた戻ります。
!S3のオブジェクト一致率が低いのは、接続「con_s3_watanabe」について今回のIDMC Metadataを使用して他のCDIタスクスキャンで読み込んだオブジェクトが割り当てたカタログソースのオブジェクトより多かったためです。今回の場合は割り当てたカタログソースが、接続「con_s3_watanabe」で読み込んだオブジェクト24個のうち4個を読み込んだということです。
先ほどのリネージュをを確認してみると、S3が反映されていました。
接続割り当てをすることで、S3のカタログソースから特定のファイルを使用しているジョブの特定が容易になりました。

例えばこれがDBなら、「このテーブルの依存関係ってなんだろう？」という場合に素早く確認することが可能です。
残りのRedshiftの接続割り当ても実施します。

3分で割り当てジョブが完了しました。

・・・が、オブジェクト一致率が0%となっています。
それもそのはず、誤ってmartスキーマのみのカタログソースを割り当ててしまっていました。

今度は以下のように、接続に対して複数のカタログソースを割り当ててみました。
するとオブジェクト一致率が100％となりました。
「なるほど、こう割り当てるのね」と思いましたが、実はまだ違いました。

ジョブステータスの表示を確認してみると、dwhとmartについては、オブジェクトがそもそも0件となっていました。

どうやら割り当てる必要がなかったようです。
dwhとmartの割り当てを解除します。
割り当てられたカタログソースが1つだけになりました。

変わらずオブジェクト一致率は100%です。
ここから言えることは、リネージュの正確性を担保するには、 対象の接続を網羅するようにカタログソースを設定してオブジェクト一致率を上げていく のが大事だということだと思います。
CDGCを確認すると、データリネージュがしっかりと表示されていることが確認できました。
 リネージュを触ってみるせっかくなのでリネージュをもう少し触ってみます。
先ほどのリネージュはDataStoreからDWHまでのETLを選択したリネージュでした。

「DataMartのテーブルを中心としたリネージュを見たいなあ」と思った場合は、先ほどの画面から簡単に数クリックでリネージュ表示可能です。
またオーバーレイという機能もあり、リネージュに付加情報を追加することができます。

いろんなメタデータが選択可能です。
用語集とデータ品質（正確性）と計算式を選択して、リネージュ上に表示させてみました。
用語集はまだ割り当ててないですが、物理名ではわかりづらいデータの意味も把握することが可能となり、データの流れの把握がさらに強化されています。

データ品質については、リネージュで確認することでどこで品質が悪くなったのか、ということが容易に確認可能で、品質改善活動が強化されます。
計算式は、どのようなデータ加工をしているかがわかります。

リネージュの電卓マークから確認することができます。

以下の例で言えば、どの項目で集約して、どのようにテーブルにデータを入れているかまでわかります。
 まとめIDMC MetadataでETLタスクをスキャンしてリネージュまで取得することが確認できました。

リアルタイム性のあるメタデータ収集をIDMC Metadataで実現してリネージュを使い倒していきましょう。
以上、どなたかのご参考になれば幸いです。